Many hosts today are multi-homed. Hence, they have multiple paths for connectivity via one or more access technologies. Regular Transmission Control Protocol (TCP)/Internet Protocol (IP) communications restrict these multi-homed hosts to use only one of the available interfaces/paths per session, where path is defined as an (source, destination) IP address pair. Internet Engineering Task Force (IETF) is currently looking into a mechanism which uses multiple paths between the communicating peers simultaneously during a communication session. IETF Request for Comments (RFC) number 6824 proposes a set of extensions to traditional TCP for multipath operations when multiple addresses are available. This is referred to as Multipath TCP (MPTCP).
The advantages of using multiple paths concurrently are:
1 Improve network resource utilization (e.g., increase bandwidth due to resource pooling)
2 Improve user experience through higher throughput
3 Allows failover from one interface to another (e.g., mobile client)
4 Allows a single data connection to use several interfaces simultaneously
A usage scenario for MPTCP is illustrated in FIG. 1 where two communicating hosts A and B are multi-homed and multi-addressed. Each host provides two separate connections to the Internet offering four different paths between them (A1-B1, A1-B2, A2-B1 and A2-B2).
A traditional TCP connection between the hosts A and B will make use of only one of the available paths whereas MPTCP connection makes use of all the four available paths between hosts A and B. An MPTCP connection is similar to a regular TCP connection and is defined in RFC 6824 as a set of one or more sub-flows, over which an application can communicate between two hosts. A “sub-flow” is defined in RFC 6824 as a flow of TCP segments operating over an individual path, which forms part of a larger MPTCP connection. A sub-flow is started and terminated similar to a regular TCP connection.
MPTCP is an end-to-end protocol which requires both hosts to support MPTCP to benefit from MPTCP. Since, MPTCP is still in its early stage of deployment, probabilities that every host on the Internet supports MPTCP are very low. To overcome this problem and benefit from MPTCP even though both communicating hosts do not support MPTCP, an MPTCP proxy may be used to convert MPTCP flows to TCP and vice versa.
One use case is illustrated in FIG. 2. An MPTCP-capable User Equipment (UE) (cf. Host A in FIG. 1) is controlled by the operator and sets up several MPTCP sub-flows to the MPTCP proxy placed in the operator's network. This proxy in turn sets up a single TCP flow to a server on the Internet (cf. Host B in FIG. 1 which is instead MPTCP capable and does not need an MPTCP proxy) which is not MPTCP capable. In the described scenario, the UE which supports MPTCP can still get the benefits of MPTCP although the server at the other end is not aware of MPTCP.
So a main principle of Multi-Path TCP (MPTCP) is to aggregate a set of TCP connections e.g. over different wireless interfaces such as a cellular Third Generation Partnership Program (3GPP) Radio Access Network (RAN) and Wireless Local Area Network (WLAN) RAN (e.g. Wi-Fi) (or even different simultaneous cellular 3GPP accesses). MPTCP has multiple sub-flows and is capable of distributing load on all sub-flows. Since the multiplexing of different connections is on TCP level, it allows separate congestion control for each sub-flow.
FIGS. 3a and 3b show the differences between standard TCP and MPTCP protocol stacks. The application interface, i.e. the socket API, is unchanged and the main changes are between this API and the IP-layer. The TCP and IP layers in the protocol stack are split between the different sub-flows.
MPTCP provides the possibility to fully and maximally utilize the different TCP sub-flows. For example, in the case of one TCP sub-flow on 3GPP access and another one on Wi-Fi access, the total throughput could be the sum of these sub-flows. FIG. 4 shows a user plane protocol architecture example for the case when MPTCP would be utilizing 3GPP Long Term Evolution (LTE) and WLAN/Wi-Fi simultaneously.
In an exemplary case of MPTCP, the UE is simultaneously connected to both LTE and Wi-Fi/WLAN. The application in the UE has opened up one TCP socket and is sending a stream of bytes on the internal API. The MPTCP layer (also called MPTCP scheduler) has established two different TCP sub-flows, sub-flow 1 via WLAN/Wi-Fi and sub-flow 2 via LTE. Both these sub-flows are towards an MPTCP Proxy that further communicates with another server using plain TCP. The MPTCP scheduler is the function that decides how the different packets are mapped to the two sub-flows. There may be one MPTCP scheduler in the UE for uplink scheduling and one in the MPTCP proxy for downlink scheduling. The MPTCP scheduler is for example applying “round-robin” scheduling i.e. first TCP segment is sent on sub-flow 2, second on sub-flow 1, third again on sub-flow 2 etc. Another example is that the MPTCP scheduler uses the sub-flow with the shortest round-trip time (RTT). Such an approach is typically used in today's MPTCP kernel prototype implementations.